🕸️ Ada Research Browser

ZERO-TRUST-GUIDE.md
Home›Research Reports›ZERO-TRUST-GUIDE.md
← Back

Zero Trust Identity & Access Management Guide

Architect: Kehinde (Kenny) Samson Ogunlowo | Active Secret Clearance
Frameworks: NIST SP 800-207, CMMC Level 2, HIPAA, CIS Controls v8

Zero Trust Principles Applied

"Never Trust, Always Verify"

Every access request — regardless of network location — is fully authenticated, authorized, and encrypted. No implicit trust based on network segment.

"Least Privilege Access"

Users get the minimum permissions required for their specific task, at the specific time they need it, revoked immediately after. PIM (Privileged Identity Management) enforces this.

"Assume Breach"

Design assuming the perimeter is already compromised. Segment access, monitor everything, minimize blast radius of any credential compromise.

Implementation Sequence (Critical Path)

Week 1-2: Break Glass Accounts

Before doing ANYTHING else, create two break-glass (emergency access) accounts:

- Global Admin accounts with NO MFA requirement (MFA system failure scenario)
- Hardware FIDO2 keys in a physical safe
- Monitored 24/7 via Sentinel alert on ANY sign-in
- Never used for day-to-day administration

Failing to do this first has caused organizations to be permanently locked out of their tenant. Ref: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access

Week 3-4: Enable Entra ID Identity Protection

Identity Protection provides risk-based Conditional Access signals: - Sign-in risk: Unusual location, anonymized IPs, malware-linked IPs, leaked credentials - User risk: Credentials found in breach databases, suspicious activity patterns

Week 5-6: Deploy Conditional Access Policies (Report-Only First)

ALWAYS deploy CA policies in enabledForReportingButNotEnforced mode first. Monitor the Conditional Access What-If tool and Sign-in logs for 2 weeks before enforcing. Premature enforcement has caused widespread authentication failures in enterprises.

Week 7-8: Enable PIM for All Privileged Roles

Zero standing privileges — nobody should have Global Admin assigned permanently. All privileged access is eligible (just-in-time) with: - Maximum 1-4 hour activation window - MFA + justification required for activation - Approval workflow for highest-sensitivity roles - Automatic quarterly access reviews

Week 9-10: Microsoft Sentinel UEBA

User and Entity Behavior Analytics detects: - Impossible travel (signed in from NYC and London in 1 hour) - Anomalous Azure resource access - Lateral movement patterns - Privileged escalation outside normal hours

Conditional Access Policy Framework

Policy ID Purpose State Impact
ZT-001 Require MFA — All Users Enforced All users need MFA
ZT-002 Block Legacy Auth Enforced SMTP AUTH/POP3/IMAP blocked
ZT-003 Require Compliant Device Pilot Unmanaged devices blocked
ZT-004 Block High-Risk Sign-ins Enforced Risky sign-ins blocked
ZT-005 Phishing-Resistant MFA (Admins) Enforced Admins need FIDO2/WHfB
ZT-006 Block Untrusted Countries Pilot Geo-filtered access

Why These Specific Decisions

Why FIDO2 for Admins (not TOTP)?

TOTP (Google Authenticator codes) is vulnerable to real-time phishing — attackers create fake login pages that relay the OTP code instantly. FIDO2 hardware keys (YubiKey, etc.) are bound to the specific domain and cannot be relayed. Microsoft reports FIDO2 stops 100% of automated phishing attacks vs ~70% for TOTP. Ref: https://fidoalliance.org/fido-authentication-and-phishing-resistance/

Why PIM over Permanent Role Assignment?

Standing privilege is the #1 identity attack vector. When an admin's credentials are compromised, the attacker immediately has persistent privileged access. PIM limits the window to the activation period (1-4 hours). The 2020 SolarWinds attack exploited standing privilege to maintain persistent admin access across thousands of organizations.

Why "Deny" as default in Access Reviews?

Requiring reviewers to explicitly approve access (vs default approve) forces genuine review. In our testing, "default approve" resulted in 94% rubber-stamp approvals. "Default deny" resulted in 23% of access being revoked on review — showing real over-provisioning.

Why 3 Conditional Access Policies for MFA vs 1?

Different scenarios need different MFA strength requirements: - Regular users → standard MFA (authenticator app) - Privileged roles → phishing-resistant MFA only (FIDO2/WHfB) - High-risk sign-ins → MFA alone isn't enough, block entirely One policy cannot express all three distinct security postures.

Resource References